A directory is, in general, an approach to organizing information. In computer networks, a directory is, typically, a repository that stores information about users, user passwords, and information about network resources that the users can access. Originally, a directory service was unique to a specific application such as e-mail or to a specific operating system. In contrast, a universal directory is independent of both applications and network operating systems.
LDAP (Lightweight Directory Access Protocol) is a software protocol for enabling applications to locate organizations, individuals, and other resources such as files and devices in a network, such as the public Internet or on a corporate intranet. LDAP is based on X.500, a CCITT (the predecessor to the ITU-T [International Telecommunication Union-Telecom Standardization]) standard for directory services in a network. LDAP is a widely accepted protocol that is supported in most, if not all, of the major directories, so it is included in various browser and e-mail client applications, and is also supported in various networking products. Version 3 of LDAP is partially described in RFC 2251 from the Network Working Group of the Internet Engineering Task Force (IETF).
In a network, a directory tells an application where in the network something is located. On TCP/IP networks, for example, LDAP allows an application to search for an individual or resources without knowing where they are located. An LDAP directory is organized in a “tree” hierarchy (DIT [Directory Information Tree]) consisting of the following levels: (1) the root node (the starting place or the source of the tree), which branches out to (2) countries, each of which branches out to (3) organizations, which branch out to (4) organizational units (divisions, departments, and so forth), which branch out to (includes an entry for) (5) individual resources, including people, files, and shared resources such as printers.
An LDAP directory can be distributed among many servers. Each distributed directory server can have a replicated version of the master directory, or of a sub-tree of the master directory, that is synchronized periodically. Therefore, distributed resources have access to the desired directory information in a distributed directory server when connection to the master directory server is lost. Currently, there are at least two replication draft protocols which can be used for implementing replication: (1) the Change Log protocol; and (2) LCUP (LDAP Client Update Protocol).
Servers implementing LCUP provide a cookie to the client (i.e., a distributed directory server) containing the state information for the client. With each replication request, the client sends the cookie, and the master directory server returns only the changes made to the master directory since the last replication to the client.
The Change Log protocol works on the basis of a change log. The master directory server has a container that contains a list of changed entries. Each change log entry contains an incremental unique change log number and the details of the entry, change type, and the changes made to the entry. This container is obtained by reading the “changeLog” attribute from the master directory server. The client retrieves all the changeLog entries with a changeLog number equal to and greater than its last replicated changeLog number for a particular directory.
The foregoing approaches are useful for performing replication of a master directory where the entire directory is replicated and distributed or where an entire sub-tree of the directory is replicated and distributed. For example, assume the following:
the top of a directory tree (or a “sub-tree”) is represented as “o=cisco.com” (at a level equivalent to level 3 above); and
one sub-tree of the directory tree is represented as “dn: ou=Users, o=cisco.com” (Note that there can be multiple such sub-trees under “o=cisco.com”); and
there are 10,000 entries under the sub-tree, similar to the following two entries.
dn: cn=userjtapi,ou=Users, o=cisco.com
objectClass: top
objectClass: inetOrgPerson
objectClass: ciscoocUser
mail: userjtapi;
dn: cn=xyz,ou=Users, o=cisco.com
objectClass: top
objectClass: inetOrgPerson
objectClass: ciscoocUser
mail: xyz.
Prior replication approaches requires replication of all 10,000 entries under “ou=Users, o=cisco.com”. However, partial replication of a directory on distributed servers is not previously available. That is, replication of only 100 of the 10,000 entries is not available in past approaches.
In this context, partial replication refers to replication of only a subset of a sub-tree of the total directory. For example, one might only want to replicate a branch or sub-tree of the master directory that includes directory information for a specific business unit, office location, etc.
Known approaches cannot maintain a partially replicated distributed directory, that is, they cannot distribute and maintain a subset of a sub-tree of a directory on a distributed directory server. The past approaches also cannot replicate or maintain a plurality of different partial replications on a plurality of different distributed directory servers. For example, LDAP defines a replication function call, but it can only replicate a complete sub-tree of the directory. Hence, based on the foregoing, there is a clear need for a technique for partially replicating directory sub-tree information from a master directory server to distributed directory servers.
Unless otherwise indicated herein, the approaches described in this section are not prior art to the claims in this application and are not admitted to be prior art by inclusion in this section.